.TH "irc_callbacks_t" 3 "10 Jan 2009" "Version 1.3" "libircclient" \" -*- nroff -*-
.ad l
.nh
.SH NAME
irc_callbacks_t \- Event callbacks structure.  

.PP
.SH SYNOPSIS
.br
.PP
\fC#include <libirc_events.h>\fP
.PP
.SS "Data Fields"

.in +1c
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_connect\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_nick\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_quit\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_join\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_part\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_mode\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_umode\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_topic\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_kick\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_channel\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_privmsg\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_notice\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_channel_notice\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_invite\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_ctcp_req\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_ctcp_rep\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_ctcp_action\fP"
.br
.ti -1c
.RI "\fBirc_event_callback_t\fP \fBevent_unknown\fP"
.br
.ti -1c
.RI "\fBirc_eventcode_callback_t\fP \fBevent_numeric\fP"
.br
.ti -1c
.RI "\fBirc_event_dcc_chat_t\fP \fBevent_dcc_chat_req\fP"
.br
.ti -1c
.RI "\fBirc_event_dcc_send_t\fP \fBevent_dcc_send_req\fP"
.br
.in -1c
.SH "Detailed Description"
.PP 
Event callbacks structure. 

All the communication with the IRC network is based on events. Generally speaking, event is anything generated by someone else in the network, or by the IRC server itself. 'Someone sends you a message', 'Someone has joined the channel', 'Someone has quits IRC' - all these messages are events.
.PP
Every event has its own event handler, which is called when the appropriate event is received. You don't have to define all the event handlers; define only the handlers for the events you need to intercept.
.PP
Most event callbacks are the types of \fBirc_event_callback_t\fP. There are also events, which generate \fBirc_eventcode_callback_t\fP, \fBirc_event_dcc_chat_t\fP and \fBirc_event_dcc_send_t\fP callbacks. 
.SH "Field Documentation"
.PP 
.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_channel\fP"
.PP
The 'channel' event is triggered upon receipt of a PRIVMSG message to an entire channel, which means that someone on a channel with the client has said something aloud. Your own messages don't trigger PRIVMSG event.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who generates the message. 
.br
\fIparams[0]\fP mandatory, contains the channel name. 
.br
\fIparams[1]\fP optional, contains the message text 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_channel_notice\fP"
.PP
The 'channel_notice' event is triggered upon receipt of a NOTICE message which means that someone has sent the client a public notice. According to RFC 1459, the only difference between NOTICE and PRIVMSG is that you should NEVER automatically reply to NOTICE messages. Unfortunately, this rule is frequently violated by IRC servers itself - for example, NICKSERV messages require reply, and are NOTICEs.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who generates the message. 
.br
\fIparams[0]\fP mandatory, contains the channel name. 
.br
\fIparams[1]\fP optional, contains the message text 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_connect\fP"
.PP
The 'on_connect' event is triggered when the client successfully connects to the server, and could send commands to the server. No extra params supplied; \fIparams\fP is 0. 
.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_ctcp_action\fP"
.PP
The 'action' event is triggered when the client receives the CTCP ACTION message. These messages usually looks like:
.br
 
.PP
.nf
 [23:32:55] * Tim gonna sleep.

.fi
.PP
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who generates the message. 
.br
\fIparams[0]\fP mandatory, the ACTION message. 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_ctcp_rep\fP"
.PP
The 'ctcp' event is triggered when the client receives the CTCP reply.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who generates the message. 
.br
\fIparams[0]\fP mandatory, the CTCP message itself with its arguments. 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_ctcp_req\fP"
.PP
The 'ctcp' event is triggered when the client receives the CTCP request. By default, the built-in CTCP request handler is used. The build-in handler automatically replies on most CTCP messages, so you will rarely need to override it.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who generates the message. 
.br
\fIparams[0]\fP mandatory, the complete CTCP message, including its arguments.
.RE
.PP
Mirc generates PING, FINGER, VERSION, TIME and ACTION messages, check the source code of \fClibirc_event_ctcp_internal\fP function to see how to write your own CTCP request handler. Also you may find useful this question in FAQ: \fBWhat is CTCP, and why do I need my own handler?\fP 
.SS "\fBirc_event_dcc_chat_t\fP \fBirc_callbacks_t::event_dcc_chat_req\fP"
.PP
The 'dcc chat' event is triggered when someone requests a DCC CHAT from you.
.PP
See the params in \fBirc_event_dcc_chat_t\fP specification. 
.SS "\fBirc_event_dcc_send_t\fP \fBirc_callbacks_t::event_dcc_send_req\fP"
.PP
The 'dcc chat' event is triggered when someone wants to send a file to you via DCC SEND request.
.PP
See the params in \fBirc_event_dcc_send_t\fP specification. 
.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_invite\fP"
.PP
The 'invite' event is triggered upon receipt of an INVITE message, which means that someone is permitting the client's entry into a +i channel.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who INVITEs you. 
.br
\fIparams[0]\fP mandatory, contains your nick. 
.br
\fIparams[1]\fP mandatory, contains the channel name you're invited into.
.RE
.PP
\fBSee also:\fP
.RS 4
\fBirc_cmd_invite\fP irc_cmd_chanmode_invite 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_join\fP"
.PP
The 'join' event is triggered upon receipt of a JOIN message, which means that someone has entered a channel that the client is on.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who joins the channel. By comparing it with your own nickname, you can check whether your JOIN command succeed. 
.br
\fIparams[0]\fP mandatory, contains the channel name. 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_kick\fP"
.PP
The 'kick' event is triggered upon receipt of a KICK message, which means that someone on a channel with the client (or possibly the client itself!) has been forcibly ejected.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who kicked the poor. 
.br
\fIparams[0]\fP mandatory, contains the channel name. 
.br
\fIparams[0]\fP optional, contains the nick of kicked person. 
.br
\fIparams[1]\fP optional, contains the kick text 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_mode\fP"
.PP
The 'mode' event is triggered upon receipt of a channel MODE message, which means that someone on a channel with the client has changed the channel's parameters.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who changed the channel mode. 
.br
\fIparams[0]\fP mandatory, contains the channel name. 
.br
\fIparams[1]\fP mandatory, contains the changed channel mode, like '+t', '-i' and so on. 
.br
\fIparams[2]\fP optional, contains the mode argument (for example, a key for +k mode, or user who got the channel operator status for +o mode) 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_nick\fP"
.PP
The 'nick' event is triggered when the client receives a NICK message, meaning that someone (including you) on a channel with the client has changed their nickname.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who changes the nick. Note that it can be you! 
.br
\fIparams[0]\fP mandatory, contains the new nick. 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_notice\fP"
.PP
The 'notice' event is triggered upon receipt of a NOTICE message which means that someone has sent the client a public or private notice. According to RFC 1459, the only difference between NOTICE and PRIVMSG is that you should NEVER automatically reply to NOTICE messages. Unfortunately, this rule is frequently violated by IRC servers itself - for example, NICKSERV messages require reply, and are NOTICEs.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who generates the message. 
.br
\fIparams[0]\fP mandatory, contains the target nick name. 
.br
\fIparams[1]\fP optional, contains the message text 
.RE
.PP

.SS "\fBirc_eventcode_callback_t\fP \fBirc_callbacks_t::event_numeric\fP"
.PP
The 'numeric' event is triggered upon receipt of any numeric response from the server. There is a lot of such responses, see the full list here: \fBNumeric reply codes from RFC1459\fP.
.PP
See the params in \fBirc_eventcode_callback_t\fP specification. 
.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_part\fP"
.PP
The 'part' event is triggered upon receipt of a PART message, which means that someone has left a channel that the client is on.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who leaves the channel. By comparing it with your own nickname, you can check whether your PART command succeed. 
.br
\fIparams[0]\fP mandatory, contains the channel name. 
.br
\fIparams[1]\fP optional, contains the reason message (user-defined). 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_privmsg\fP"
.PP
The 'privmsg' event is triggered upon receipt of a PRIVMSG message which is addressed to one or more clients, which means that someone is sending the client a private message.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who generates the message. 
.br
\fIparams[0]\fP mandatory, contains your nick. 
.br
\fIparams[1]\fP optional, contains the message text 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_quit\fP"
.PP
The 'quit' event is triggered upon receipt of a QUIT message, which means that someone on a channel with the client has disconnected.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who is disconnected 
.br
\fIparams[0]\fP optional, contains the reason message (user-specified). 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_topic\fP"
.PP
The 'topic' event is triggered upon receipt of a TOPIC message, which means that someone on a channel with the client has changed the channel's topic.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who changes the channel topic. 
.br
\fIparams[0]\fP mandatory, contains the channel name. 
.br
\fIparams[1]\fP optional, contains the new topic. 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_umode\fP"
.PP
The 'umode' event is triggered upon receipt of a user MODE message, which means that your user mode has been changed.
.PP
\fBParameters:\fP
.RS 4
\fIorigin\fP the person, who changed the channel mode. 
.br
\fIparams[0]\fP mandatory, contains the user changed mode, like '+t', '-i' and so on. 
.RE
.PP

.SS "\fBirc_event_callback_t\fP \fBirc_callbacks_t::event_unknown\fP"
.PP
The 'unknown' event is triggered upon receipt of any number of unclassifiable miscellaneous messages, which aren't handled by the library. 

.SH "Author"
.PP 
Generated automatically by Doxygen for libircclient from the source code.
